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REMARKS 

Reconsideration of the rejections set forth in the Office Action is respectfully requeued. 
By this Amendment, claims 5, 14, 22, and 26-28 have been canceled without prejudice or 
disclaimer and claims 1, 3-4, 6, 7 S 9, 10, 12, 13, 15, 16, 18, 20, and 21 have been amended. 
Currently, claims 1-4, 6-13, 15-22, and 23-25 are pending in this application. 

Rejection under 35 USC 101 

Claims 10-17 and 26-28 were rejected under 35 USC 10L Applicants have amended 
claim 10 to overcome the rejection of claims 10-17, and have canceled claims 26^28. 
Accordingly the Examiner is respectfully requested to withdraw the rejection under 35 USC 101 . 

Rejection of claims 1-28 under 35 USC 10 2 over Tang 

Claims 1-28 were rejected under 35 USC 102 as anticipated by Tang et al. (U.S. Patent 
No. 6,839,348). This rejection is respectfully traversed in view of the amendments to the claims, 
and the following arguments. 

Multicast trees are commonly established to distribute information to multicast 
participants in an efficient manner. As noted in the background of the invention, there are 
several routing protocols that may be used to establish a multicast tree, two of which are Protocol 
Independent Multicast (PIM) and Distance Vector Multicast Routing Protocol (DVMRP). (See 
Specification at page 2, lines 4-6). Once the multicast tree has been established, information 
may be transmitted over the multicast tree. Since not every network device that is connected to 
the multicast tree may wish to participate in every multicast, or may not be authorized to 
participate in the multicast, a separate set of protocols have been developed to control 
membership in the multicast. One common protocol that is used to control membership in a 
multicast is Internet Group Management Protocol (IGMP). A router will store routing 
information to route multicast packets over the multicast tree to cause the multicast packets to 
reach those destinations on the network that have joined a particular multicast. Thus, when a 
node joins a multicast, it will send an IGMP JoinGroup message. This will cause routers on the 
network to install routing entries into their Routing Information Bases to allow packets to be 
forwarded on the new branch of the multicast tree to the newly joined node. 
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There are instances where it is necessary for a network management application to 
recreate a multicast tree to see how the tree has been created. Unfortunately, the information that 
the network management application needs to create the tree is the multicast routing information, 
since this is the information that actually shows how packets are forwarded on the tree by the 
nodes on the network. Since the multicast routing information that is stored in the multicast 
routing information base is protocol dependent, i.e. is created using PIM or DVMRP, a network 
management program configured to read one type of routing information can't recreate a 
multicast tree that was created using the other type of multicast routing protocol. Thus, for 
example, a management program configured to read PIM routing information could not trace a 
multicast tree implemented using DVMRP, or vise-versa* 

Applicants determined that the standard Management Information Base (MIB) could be 
used to store protocol independent multicast information that could be accessed by a network 
management application to build a multicast tree representing the multicast (Specification at 
page 7, line 27-Page 8, line 1), Applicants have amended claim 1 to recite a "method of 
producing a multicast tree bv a network management application." (emphasis added). Claim- 1 
has further been amended to recite that routers on the network each include a MIB containing 
protocol independent multicast routing information. Additionally, claim 1 has been amended to 
recite that the network management application accesses the plurality of MIBs, retrieves 
protocol independent multicast routing information from the MIBs, and traces the retrieved 
protocol independent multicast routing information to form a representation of the multicast tree 
in the netwcik management application. 

Tang does not teach or suggest that MIBs should contain protocol independent multicast 
routing information, or that a network management application should access the MIBs, retrieve 
the protocol independent multicast routing information, and trace the information to form a 
representation of the multicast tree. 

Storage of protocol independent multicast routing information in a MIB was previously 
addressed in connection with claim 5. Claim 5 has now been canceled and the features of claim 
5 have been incorporated into claim 1. With respect to claim 5, the Examiner took the position 
that Tang taught these features citing several portions of Tang. Applicants have reviewed these 
sections of Tang and it appears that Tang does not use the MIBs to store multicast routing 
information. 

• 
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In Tang, each Multicast Network Device (MND) that is coupled to a VLAN region is 
responsible for distributing multicast messages to a disjoint set of the VLAN domains defined 
within the region. (Col. 9, liens 42-46). The network administrator will assign one or more 
VLAN domain to each MND, and will communicate the assignment to the MNDs using SNMP 
or CLI (Col. 9, lines 46-59). The MNDs will then store the assignment in their MIB so that the 
MND may determine, at startup, the VLAN domain(s) for which it is responsible. 

The Examiner has taken the position that the VLAN IDs and MVLAN IDs are used as 
protocol independent multicast routing information. Specifically, the Examiner has taken the 
position that since the VLAN or MVLAN identifiers are used to identify what VLAN or 
MVLAN domains the multicast messages are distributed to through the access port, that these 
fields are being used as protocol independent multicast routing information. 

The VLAN and MVLAN identifiers are not routing information. They are identifiers that 
are used to identify domains within a particular VLAN region. Note, in this regard, that the 
MVLAN identifies multiple VLANS whereas a VLAN identifies a particular VLAN. 

In Tang, the MNDs each have a multicast routing table 308 that is used to hold multicast 
route emries. (See e.g. Tang at Col. 15, lines 21-22 - "an MND creates a corresponding P1M 
shared-tree route entry in its multicast routing table"). When an MND receives a JoinGroup 
message, it will create a shared-tree route entry {* G} in its multicast routing table 308. (Tang at 
col. 15, lines 19-22). Each entry in the multicast routing table 308 includes the source address 
314, the multicast group destination address 316, the outgoing interface list (OIF) 318, and the 
incoming interface list 320. (See Tang Fig. 3) 

As members joint the multicast, they will issue IGMP JoinGroup messages. An MND 
will receive the JoinGroup message and determine the interface on which the message was 
received. The VLAN ID of the interface on which the message was received will be added to the 
outgoing interface list 318 (Tang at col. 15, lines 35-50). Where the MND is not responsible for 
the VLAN IDs or MVLAN IDs, however, it will not add any entries to the outgoing interface 
list. (Tang at Col. 15, lines 61-64). Thus, the VLAN IDs are not multicast group routing 
information, but rather are used to identify interfaces on the MND. Additionally, the VLAN IDs 
and MVLAN IDs are stored in the multicast routing table 308 and thus, even if they could be 
considered to be multicast information, they are not stored in the MIB as claimed. 
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Moreover, the fact that the network operator is able to administratively tell a particular 
MND which VLAN IDs and MVLAN IDs are available for use on the network, and store those 
values in the MTB, does not mean that the VLAN IDs or MVLAN IDs that are stored in the MIB 
represent a multicast tree. Specifically, the network management application could not access 
the MIB of the MND, retrieve the VLAN and MVLAN assignments, and use that information to 
recreate the tree. Thus, regardless of the Examiner's interpretation, Tang does not anticipate 
claim 1, which requires the network management application to be able to access the MIB, 
retrieve protocol independent multicast routing information from the MTB, and use the retrieved 
multicast routing information to form a representation of the multicast tree. Accessing the 
VLAN IDs stored in Tang's MIB would tell the network management application what VLANs 
and MVLANs were serviced by the MND, but would not allow the application to form a 
representation of any of the multicast trees passing through that particular MND. 

Applicants respectfully submit that the claims, as amended, are not anticipated by Tang. 
Accordingly, applicants respectfully request that the rejection under 35 USC 1 02 be withdrawn. 

Conclusion 

Applicants respectfully submit that the claims pending in this application are in condition 
for allowance and respectfully request an action to that effect. If the Examiner believes a 
telephone interview would further prosecution of this application, the Examiner is respectfully 
requested to contact the undersigned at the number indicated below. 

If any fees are due in connection with this filing, the Ccmimissioner is hereby authorized 
to charge payment of the fees associated with this communication or credit any overpayment to 
Deposit Account No. 502246 (Ref. NN-1 3774). 

Respectfully Submitted 



Dated: January 8, 2008 

John C. Gorecki, Esq. 
P.O. Box 553 
Carlisle, MA 01741 
Tel: (978) 371-3218 
Fax: (978) 371-321 9 
john@gorecki.us 




C. Gorecki, Reg. No. 38,471 
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